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Resumen —El objetivo de este trabajo se centra en investigar 
los efectos que conlleva realizar experimentos en ingeniería de 
software (IS) empleando como sujetos experimentales a estu¬ 
diantes de pregrado cursando su primer año de estudios de 
la carrera en ingeniería de software. De manera particular en 
este trabajo se investiga la efectividad medida en porcentaje de 
defectos observados y observables de las técnicas de pruelja de 
software funcional (caja negra) y estructural (caja blanca). 

Con respecto a los defectos observados por los sujetos, ambas 
técnicas obtuvieron una efectividad del 4 %. Con respecto a los 
defectos observables por los casos de prueba, la técnica funcional 
es ligeramente superior (21 %) que la técnica estructural (16 %), 
aunque esta diferencia no es significativa. Se observa un nivel de 
inexperiencia considerable en los sujetos para aplicar las técnicas. 
Dado los hallazgos encontrados, se sugiere emplear sujetos de 
pregrado con un nivel mayor de experiencia. 

I. Introducción 

La detección de defectos es una actividad crítica en la 
construcción de sistemas software. En general, la comunidad 
en ingeniería de software acepta que la detección de defectos 
debiera llevarse a cabo tanto con técnicas de inspección 
basadas en lectura de códigos así como por técnicas de prue¬ 
ba dinámicas como son las técnicas funcional y estructural, 
conocidas también como técnicas caja negra y caja blanca, 
respectivamente m. 

El trabajo aquí reportado es una extensión de trabajos 
previos m, a, 0, 0 en donde se ba investigado, entre 
otros aspectos, la efectividad de varias técnicas de prueba 
de software. A diferencia de estos trabajos previos, en esta 
investigación se busca analizar la efectividad de las técnicas 
de caja negra y caja blanca aplicadas por sujetos novicios 
de pregrado, con el fin de realizar recomendaciones sobre el 
uso de este tipo de sujetos en experimentos controlados en 
ingeniería de software. El resto de este documento se estructura 
de la siguiente manera: en la sección [TI] se describen las dos 
técnicas de prueba estudiadas. En la sección [III] se presenta 
el contexto del experimento. En la sección |IV] se describe el 
análisis estadístico. Por último, en la sección lY] se presenta la 
discusión y conclusiones. 

II. Técnicas de prueba de software 
II-A. Técnica funcional o caja negra 

También conocida como prueba de comportamiento, este 
tipo de técnica se basa en la especificación del programa o 


componente a ser probado para elaborar los casos de prueba. 
El componente se ve como una “caja negra” cuyo compor¬ 
tamiento sólo puede ser determinado estudiando sus entradas 
y las salidas obtenidas a partir de ellas. No obstante, como el 
estudio de todas las posibles entradas y salidas de un programa 
es impracticable se selecciona un conjunto de ellas sobre las 
que se realizan las pruebas. Para seleccionar el conjunto de 
entradas y salidas sobre las que trabajar, bay que tener en 
cuenta que en todo programa existe un conjunto de entradas 
que causan un comportamiento erróneo en el sistema, y como 
consecuencia producen una serie de salidas que revelan la 
presencia de defectos. Entonces, dado que la prueba exhaustiva 
es imposible, el objetivo final es encontrar una serie de datos 
de entrada cuya probabilidad de pertenecer al conjunto de 
entradas que causan diebo comportamiento erróneo sea lo más 
alto posible lól, 171. 

Para especificar los casos de prueba de caja negra existen 
distintos criterios, algunos de ellos son; 

■ Particiones de clase de equivalencia. Una clase 
de equivalencia representa un conjunto de estados 
válidos o no válidos para condiciones de entrada. 
Típicamente una condición de entrada es un valor 
numérico específico, un rango de valores, un conjunto 
de valores relacionados o una condición lógica. 

■ Análisis de Valores Límite, los errores tienden a 
darse más en los límites del campo de entrada que 
en el centro. El análisis de valores límite lleva a 
una elección de casos de prueba que ejerciten dichos 
valores. El análisis de valores límite (AVE) es una 
técnica de diseño de casos de prueba que completa 
a la partición equivalente. En lugar de seleccionar 
cualquier elemento de una clase de equivalencia, el 
AVE lleva a la elección de casos de prueba en los 
extremos de la clase. En lugar de centrarse solamente 
en las condiciones de entrada, el AVE obtiene casos 
de prueba también para el campo de salida. 

II-B. Técnica estructural o caja blanca 

A este tipo de técnica se le conoce también como técnica 
de caja transparente o de cristal. Esta técnica se centra en 
cómo diseñar los casos de prueba atendiendo al comporta¬ 
miento interno y la estructura del programa. Se examina así la 
lógica interna del programa sin considerar los aspectos de 
rendimiento. 


El objetivo de la técnica es diseñar casos de prueba 
para que se ejecuten, al menos una vez, todas las sentencias 
del programa, y todas las condiciones tanto en su vertiente 
verdadera como falsa ©, E). 

Como se ha indicado, puede ser impracticable realizar una 
prueba exhaustiva de todos los caminos de un programa. Por 
ello se han definido distintos criterios de cobertura lógica, que 
permiten decidir qué sentencias o caminos se deben examinar 
con los casos de prueba. Estos criterios son: 

■ Cobertura de sentencias. Se escriben casos de prueba 
suficientes para que cada sentencia en el programa se 
ejecute, al menos, una vez. 

■ Cobertura de decisión. Se escriben casos de prueba 
suficientes para que cada decisión en el programa se 
ejecute una vez con resultado verdadero y otra con el 
falso. 

■ Cobertura de condiciones. Se escriben casos de 
prueba suficientes para que cada condición en una 
decisión tenga una vez resultado verdadero y otra 
falso. 

■ Cobertura de condición múltiple. Se escriben casos 
de prueba suficientes para que todas las combina¬ 
ciones posibles de resultados de cada condición se 
invoquen al menos una vez. 

■ Cobertura de caminos. Se escriben casos de prueba 
suficientes para que se ejecuten todos los caminos de 
un programa. Entendiendo camino como una secuen¬ 
cia de sentencias encadenadas desde la entrada del 
programa hasta su salida. 

III. Contexto del experimento 

Tomando como referencia el proceso general de experimen¬ 
tación en ingeniería de software ||8l a continuación se detalla 
el experimento aquí reportado. 

III-A. Definición 

Las hipótesis de trabajo para este experimento se definen de 
la siguiente manera: Existe al menos una técnica de prueba de 
software (técnica funcional por particionamiento de clases de 
equivalencia [PCE], o estructural por cobertura de decisiones 
[Cob. Dec.]) tal que ésta difiere del resto con respecto a su 
efectividad. 

Hq\ efectividad en PCE = Cob. Dec. 

Hi'. efectividad en PCE ^ Cob. Dec. 

En este contexto, la efectividad es medida con dos métricas: 
defectos observados por los sujetos y defectos observables por 
los casos de prueba especificados por los sujetos. 

Los defectos observados indican el porcentaje de defectos 
que el sujeto es capaz de observar tras aplicar alguna de las 
técnicas de prueba de software. 

Por otra parte, los defectos observables indican el porcen¬ 
taje de defectos que son revelados por los casos de prueba 
especificados por los sujetos. 


Cabe señalar que el porcentaje de defectos observados 
puede ser distinto que el porcentaje de defectos observables. 
Por ejemplo, un sujeto quien especifica varios casos de prueba, 
que en conjunto revelan tres de seis posibles defectos, es capaz 
de observar sólo un defecto de los tres revelados por sus casos 
de prueba. En este caso el porcentaje de defectos observados 
es de 17 %, mientras que el porcentaje de defectos observables 
es de 50%. 

III-B. Diseño 

Con el fin de estudiar posibles interacciones entre los efec¬ 
tos de la técnica y del programa instrumentado, se empleó un 
diseño factorial con dos factores y dos niveles. El primer factor 
representa la técnica de prueba y contiene dos niveles corres¬ 
pondientes con cada tipo de técnica: funcional y estructural. 
El segundo factor representa el programa instrumentado, en 
este caso se emplearon dos programas donde cada programa 
corresponde con un nivel de este segundo factor. En total se 
tienen cuatro posibles combinaciones entre los niveles de estos 
dos factores. 

Las combinaciones factor-nivel en el experimento son 
asignadas de forma aleatoria a las unidades experimentales, en 
este caso, los sujetos. Este tipo de diseño permite el estudio 
del efecto de cada factor (técnica y programa) sobre la variable 
respuesta (efectividad), así como el efecto de las interacciones 
entre factores sobre dicha variable (técnica-programa). En la 
Tabla U se muestra la estructura de este diseño así como 
las combinaciones que se asignaron de forma aleatoria a los 
sujetos. 


Tabla I. DISEÑO FACTORIAL EMPLEADO. 


ProgramaAT éc nica 

Funcional 

Estructural 

cmdline 

funcional, cmdline 

estructural, cmdline 

ntree 

funcional, ntree 

estructural, ntree 


III-C. Ejecución 

El experimento aquí reportado se realizó a inicios de marzo 
de 2013 en la asignatura de programación. Esta asignatura 
se imparte en el segundo semestre de la Licenciatura en 
Ingeniería de Software de la Eacultad de Matemáticas de la 
Universidad Autónoma de Yucatán (EMat-UADY). Los alum¬ 
nos participantes como sujetos en este experimento cursaron 
durante el semestre anterior la asignatura de fundamentos de 
programación. 

Semanas previas al experimento los alumnos inscritos al 
curso de programación recibieron entrenamiento sobre el fun¬ 
cionamiento y aplicación de las técnicas de prueba de software. 
Una vez explicado el funcionamiento de las técnicas, los 
sujetos aplicaron cada técnica a un ejercicio de programación 
instrumentado con algunos defectos. 

Ya finalizado el entrenamiento y en una sesión indepen¬ 
diente se realizó el experimento. Se asignó de manera aleatoria 
las cuatro combinaciones de tratamientos descritas en la Tabla 
|I] a los sujetos. En total participaron 31 sujetos. Los sujetos 
usaron una herramienta web para registrar información refe¬ 
rente al diseño de sus casos de prueba y defectos observados 
de acuerdo a la técnica y programa asignado. 









Los programas instrumentados que se usaron en este expe¬ 
rimento se escribieron en el lenguaje de programación C. En 
cada programa se inyectaron seis defectos con el fin de evaluar 
la efectividad de las dos técnicas de prueba. Los defectos se 
tomaron como referencia de la clasificación propuesta en Q- 
Cada programa tiene una longitud aproximada de 250 LOC. 

A continuación se detalla de manera general el procedi¬ 
miento de aplicación de ambas técnicas. Con respecto a la apli¬ 
cación de la prueba funcional, el sujeto recibe la especificación 
del programa instrumentado sin tener acceso al código fuente. 
Con la especificación el sujeto define clases de equivalencia 
válidas y no válidas. A continuación se construyen casos de 
prueba usando como referencia las clases de equivalencia. Una 
vez especificados los casos de prueba el sujeto tiene acceso 
de ejecución al programa instrumentado y ejecuta sus casos 
de prueba. Esta actividad concluye cuando el sujeto registra 
las salidas observadas de los casos de prueba ejecutados. La 
siguiente actividad consiste en volver a revisar la especificación 
con el fin de identificar posibles defectos revelados en las 
salidas de los casos de prueba especificados. La aplicación 
de esta técnica concluye una vez que el sujeto registra los 
defectos observados. 

Con respecto a las pruebas estructurales, el sujeto recibe el 
código fuente impreso pero no la especificación. A partir del 
código fuente el sujeto construye casos de prueba intentando 
cubrir el 100% de las ramificaciones de flujo que pudiera 
alcanzar el código del programa. Una vez especificados los 
casos de prueba el sujeto usa una versión instrumentada del 
programa para ejecutar sus casos de prueba. Después de 
ejecutar los casos de prueba, el sujeto registra las salidas 
observadas. Posteriormente el sujeto accede a la especificación 
del programa con el fin de identificar posibles defectos en las 
salidas observadas. La aplicación de esta técnica finaliza con 
el registro de los defectos observados. 

IV. Análisis 

La ecuación O describe el modelo estadístico empleado 
dado el diseño factorial descrito en la sección m 

ÍJijk = + cni + /3j + {aj3)ij + Cijk (1) 

Donde p es el promedio general, representa el efecto 
de la técnica i, Pj representa el efecto del programa j, {aP)ij 
es el efecto de la interacción entre los tratamientos i y j, k 
representa las réplicas en cada combinación de tratamientos, y 
e es el error aleatorio que asume una distribución normal de 
promedio 0 y varianza cr^. Este modelo emplea el análisis de 
varianza (ANOVA) para evaluar los diferentes componentes del 
modelo descrito como son; los tratamientos, sus interacciones 
así como el error aleatorio Eoi, uní- 

El ANOVA proporciona una prueba estadística para deter¬ 
minar si los promedios de varios grupos de datos son todos 
iguales. La hipótesis nula asume que todos los grupos son 
simplemente muestras aleatorias de la misma población. Este 
supuesto implica que todos los tratamientos tienen el mismo 
efecto (quizás ninguno). Rechazar la hipótesis nula implica que 
los distintos tratamientos producen un efecto diferente. 

Antes de obtener cualquier conclusión sobre el modelo 
estadístico se deben evaluar los siguientes supuestos: 1) las 


observaciones, en este caso las métricas recabadas sean inde¬ 
pendientes (independencia); 2) la varianza sea la misma para 
todas las observaciones (homocedasticidad); las observaciones 
en cada grupo de tratamientos tengan una distribución normal 
(normalidad). 

El primer supuesto se cumple por el principio de alea- 
toriedad usado en este diseño experimental, donde todas las 
mediciones de una muestra no están relacionadas con aquellas 
pertenecientes a otra muestra. Los otros dos supuestos se 
evalúan a través de los residuos estimados (i.e. error aleatorio, 

e^Jk) im, mil. 

El supuesto de homocedasticidad puede evaluarse a través 
de la prueba estadística de Levene ma donde un valor p 
significativo indica desigualdad de varianzas por lo que el 
supuesto de homocedasticidad es violado. 

Por otra parte el supuesto de normalidad puede evaluarse 
con la prueba estadística de Kolmogorov-Smirnov mi, ma, 
donde un valor p significativo indica una diferencia entre la 
distribución del estadístico (en este caso los residuos estanda¬ 
rizados del conjunto de observaciones) y la distribución pobla- 
cional (en este caso una distribución normal). Esta diferencia 
significativa sugiere una violación al supuesto de normalidad. 

IV-A. Análisis con respecto a defectos observados 

En la Tabla mi se presenta el ANOVA con respecto a los 
defectos observados por los sujetos tras aplicar las técnicas. 


Tabla II. ANOVA CON RESPECTO A DEEECTOS OBSERVADOS. 


Component 

Df 

Sum Sq 

Mean Sq 

F valué 

p-value 

técnica 

1 

0.6 

0.60 

0.011 

0.916 

programa 

1 

128.5 

128.49 

2.424 

0.131 

técnica:programa 

1 

89.0 

88.97 

1.678 

0.206 

residuals 

27 

1431.3 

53.01 




Como se observa en en la Tabla HJ los factores principales 
(técnica y programa) así como la interacción técnica-programa 
no muestran diferencias significativas, es decir, ambas técnicas 
muestran una efectividad similar. 

Con respecto al supuesto de normalidad, la prueba de 
Kolmogorov- S mimo v m, ma arroja un valor p = 0.04719 
indicando falta de normalidad en los residuos estandarizados. 
Esta falta de normalidad se presenta debido a que la mayoría 
de sujetos no observaron defectos en los programas. Referente 
al supuesto de homocedasticidad, la prueba de Levene m 
arroja un valor p = 0.2727 sugiriendo la aceptación de la 
hipótesis nula a favor de la igualdad de varianzas. 

En la Tabla [111] se muestran los análisis descriptivos de los 
factores principales técnica y programa. 

Tabla III. ANÁLISIS DESCRIPTIVOS CON RESPECTO A DEEECTOS 
OBSERVADOS. 



n 

mean 

sd 

min 

max 

técnica funcional 

16 

4.17% 

7.46 

0% 

16.67% 

técnica estructural 

15 

4.45 % 

7.63 

0% 

16.67 % 

programa cmdline 

16 

6.25 % 

8.34 

0% 

16.67 % 

programa ntree 

15 

2.22 % 

5.87 

0% 

16.67% 


























IV-B. Análisis con respecto a defectos observables 

En la Tabla |IV] se presenta el ANOVA con respecto a los 
defectos observables por los casos de prueba especificados por 
los sujetos. 


Tabla IV. ANOVA CON RESPECTO A DEFECTOS OBSERVABLES POR 
LOS CASOS DE PRUEBA. 


Component 

Df 

Sum Sq 

Mean Sq 

F valué 

p-value 

técnica 

1 

216 

215.8 

0.791 

0.382 

programa 

1 

2 

1.7 

0.006 

0.938 

técnica:programa 

1 

389 

389.2 

1.426 

0.243 

residuals 

27 

7367 

272.9 




De acuerdo a los resultados de la Tabla IIVI los facto¬ 
res principales (técnica y programa) así como la interacción 
técnica-programa no muestran diferencias significativas, es 
decir, ambas técnicas muestran una efectividad similar. 

Con respecto al supuesto de normalidad, la prueba de 
Kolmogoro V- S mirnov m, El arroja un valor p — 0.5312 
indicando la aceptación de la hipótesis nula a favor de la 
normalidad. Referente al supuesto de homocedasticidad, la 
prueba de Levene El arroja un valor p = 0.2562 sugiriendo 
la aceptación de la hipótesis nula a favor de la igualdad de 
varianzas. 

En la Tabla |V] se muestran los análisis descriptivos de los 
factores principales técnica y programa con respecto a esta 
métrica. 

Tabla V. ANÁLISIS DESCRIPTIVOS CON RESPECTO A DEFECTOS 
OBSERVABLES. 



n 

mean 

sd 

min 

max 

técnica funcional 

16 

20.83% 

12.91 

0% 

50% 

técnica estructural 

15 

15.56% 

19.38 

0% 

50% 

programa cmdline 

16 

18.75% 

15.96 

0% 

50% 

programa ntree 

15 

17.78% 

17.21 

0% 

50%. 


V. Discusión y conclusiones 

En la Tabla IVll se muestran resultados de trabajos previos 
que han analizado la efectividad de las técnicas aquí estudia¬ 
das. La efectividad está representada como el porcentaje de 
defectos observados por los sujetos tras aplicar alguna de las 
técnicas. 


Tabla VI. DEFECTOS OBSERVADOS EN TRABAJOS PREVIOS. 


Experimento 

Téc. Funcional 

Téc. Estructural 

Kamsties y Lott, 1994 

51 % 

52% 

Kamsties y Lott, 1995 

62% 

56%. 

Roper et al., 1997 

55% 

57% 

Juristo y Vegas, 2003 

62% 

58% 

Experimento aquí reportado 

4.2% 

4.5% 


Como se observa en la Tabla IVj los resultados aquí re¬ 
portados muestran un porcentaje inferior en la efectividad de 
las técnicas. A diferencia del resto de trabajos previos, en este 
experimento se emplearon estudiantes de pregrado cursando su 
primer año de la carrera, mientras que en los trabajos previos 
se emplearon estudiantes cursando su tercer y cuarto año de 
la carrera. 


Con respecto a los defectos observables por los casos de 
prueba, se obtuvieron porcentajes mayores que los defectos 
observados. Por ejemplo, en el caso de la técnica funcional, 
los casos diseñados por los sujetos en promedio revelaron el 
21 % de los defectos mientras que para la técnica estructural 
el 16%. Los porcentajes de defectos observables arrojados en 
este experimento sugieren una falta de experiencia por parte 
de los sujetos para aplicar las técnicas aquí estudiadas. 

De manera general, los sujetos no fueron capaces de 
observar los defectos que revelaron sus casos de prueba. Se 
observa también que en el programa cmdline se identificaron 
el mayor número de defectos. Los resultados aquí reportados 
pueden servir como referente para que otros investigadores 
tengan en cuenta el nivel de experiencia de los sujetos al 
momento de realizar experimentos en esta disciplina. 
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